In the field of data network management, data transport networks are made up of a collection of managed data transport equipment. Data services are provisioned over the managed data transport equipment.
In a competitive market place, due to a recent explosive technological development, the network management and service provisioning task is complicated by many factors including: multiple data network equipment vendors having multiple approaches in implementing the data network equipment; a multitude of data transport technologies, with each vendor specializing in a sub-group of the multitude of data transport technologies; a multitude of network management and service provisioning protocols, with each vendor implementing only a sub-group of the multitude of network management and service provisioning protocols; a multitude of auxiliary network management and service provisioning equipment employing yet another multitude of network management and service provisioning technologies; etc.
Data transport equipment includes, but is not limited to: data switching equipment, routers, bridges, access nodes providing a multiplexing function, Remote Access Servers (RAS), distribution nodes providing a demultiplexing function, Customer Premise Equipment (CPE), etc. with next generation data transport equipment in development.
With regards to data network equipment, for example data switching nodes schematically shown in FIG. 1, a vendor may chose to implement an integral device 110 having a data switching processor and a group of ports 112, while another vendor may chose a customizable implementation of a data switching node 120 including: a switching fabric, an equipment rack divided into shelves, each shelf 122 having slot connectors for connection with interface cards, each interface card 124 having at least one port 112. Although conceptually the two data switching nodes 110 and 120 provide the same data switching function, each implementation is adapted for a different environment: the former data switching node 110 being more adapted to provide enterprise solutions as a private data network node, perhaps being further adapted to enable access to public data services; while the latter data switching node 120 is better adapted for high data throughput in the core of public data transport networks. Typically the former (110) implements a small number of data transport protocols while for the latter (120), data transport protocols are implemented on interface cards 124 and/or ports 112—providing for a flexible deployment thereof. All data network equipment is subject to design choices which are bound to be different from vendor to vendor.
Data transport technologies include: electrical transmission of data via copper pairs, coaxial cable, etc: optical transmission of data via optical cables; free space optical interconnects, etc.; wireless transmission of data via radio modems, microwave links, wireless Local Area Networking (LAN), etc.; with next generation data transport technologies under development.
Data transport protocols used to convey data between data transport equipment includes: Internet Protocol (IP), Ethernet technologies, Token-Ring technologies, Fiber Distributed Data Interface (FDDI), Asynchronous Transmission Mode (ATM), Synchronous Optical NETwork (SONET) transmission protocol, Frame Relay (FR), X-25, Time Division Multiplexing (TDM) transmission protocol, Packet-Over-SONET (POS), Multi-Protocol Label Switching (MPLS), etc. with next generation data transport protocols under development.
The physical data network equipment alluded to above is part of a larger body of managed data network entities enabling the provision of data services. The data network entities also include, but are not limited to: virtual routers, logical ports, logical interfaces, end-to-end data links, paths, virtual circuits, virtual paths, etc.
Network management and service provisioning enabling technologies include, but are not limited to protocols: Simple Network Management Protocol (SNMP), Common Management Information Protocol (CMIP), Command Line Interface (CLI), etc.; as well as devices: special function servers, centralized databases, distributed databases, relational databases, directories, network management systems, etc. with next generation devices and technologies under development.
Network management and service provisioning solutions include Network Management Systems (NMS) 130 enabled via special purpose software applications coded to configure and control the above mentioned data network entities. Such software applications include, but are not limited to: inventory reporting, configuration management, statistics gathering, performance reporting, fault management, network surveillance, service provisioning, billing & accounting, security enforcement, etc.
It is a daunting task to provide network management and service provisioning solutions taking into account the permutations and combinations of the elements presented above. Prior art approaches to providing network management and service provisioning solutions include the coding of hundreds of software applications with knowledge of hundreds of data networking entities using tens of data transmission and network management protocols. Some prior art solutions attempt to code all-encompassing large monolithic network management and service provisioning software applications.
Coding, deploying, maintaining, and extending such software applications for network management and service provisioning has been and continues to be an enormous undertaking as well as an extremely complex procedure. Such software applications require a large number of man-hours to create, frequently are delivered with numerous problems, and are difficult to modify and/or support. The difficulty in creating and supporting large applications is primarily due to the inability of existing software development paradigms to provide a simplification of the software development process. In accordance with current coding paradigms, the complexity of the software applications has been shown to increase as an exponential function of the number of different operations that are expected to be performed. Large programming efforts suffer in terms of reasonable performance, reliability, cost of development, and reasonable development cycles.
Object Oriented Programming (OOP) attempts to improve productivity whenever a problem can be simplified by decomposing it into a set of black-box objects. Object oriented programming depends heavily upon the benefits of data hiding, inheritance, and polymorphism to simplify software design. If a network management and service provisioning solution cannot be subdivided into objects, object oriented programming does not offer significant productivity improvements. Moreover, heavy reliance on object oriented programming to achieve compact code intending to reduce the size of software applications and perhaps development time, suffers from deeply nested function calls which creates a processing overhead leading to inefficient code. Deep nesting of function calls obscures the implementation paradigms used; thereby negatively impacting code debugging, code maintenance, and further development thereof.
Every data network entity has operational parameters associated therewith. Associations between data network entities are also made to enable: service provisioning (signaling, data transport, billing, etc.), providing redundancy (equipment, transport, bandwidth, etc.) as well as providing network management related data transport (network status updates, alarms, etc.)
In the field of data network management, typically data network elements have a network management interface complying to the SNMP protocol mentioned above. There are data network elements which do not support the SNMP protocol either by design or because these devices have been deployed prior to the standardization of the SNMP protocol. Also there are data network elements which do support the SNMP protocol, but by design these devices do not support all SNMP capabilities. The ability to configure data network elements using a Command Line Interface (CLI) is more common. The CLI is a text based human-machine mode of interaction making use of string commands and textual display of information. Typically CLI interfaces are used by an analyst to manually enter CLI commands to configure and control a single data network element for management thereof and in provisioning of data network services therethrough. The entry of CLI commands is considered to be a lengthy and error prone procedure. The industry has been searching for methods to automate CLI based configuration and control tasks.
A development attempt towards this end has been made through the establishment of the SNMP protocol as mentioned above. Although the SNMP protocol has been established, it is not implemented on all data network equipment, and not all data network equipment implements all SNMP capabilities.
Various data network element manufacturers have provided an interface to configure a data network element through the CLI interface. Such software applications tend to be proprietary and tend to address the configuration of one particular data network element as it was seen fit by the equipment vendor at the time of the development. Typically, such proprietary interfaces are non-extensible and do not lend themselves to integrated management of data network resources rendering their usefulness very limited.
Known attempts of configuration and control of data network elements includes a script based technique proposed by CISCO Systems Inc. The methods used include the manual creation of batch file scripts from CLI commands, where each script addresses a particular change in the configuration of a particular data network element. Such a script of CLI commands is downloaded to the particular data network element and it is issued for execution to carry out the desired changes. This attempt relies on the fact that all CISCO data network elements use the same set of CLI commands known as a vocabulary and grammar. Such solutions tend to be limited to a particular vendor equipment, i.e. CISCO routers. Furthermore, the scripts are issued with the expectation that the desired change is carried out.
Typically CLI commands return command completion codes including error codes, which have to be returned and interpreted by an analyst to make a decision whether the issued commands have had the desired effect. In issuing scripts to be executed, as mentioned above, the technique typically does not provide command completion code processing. Scripts including error message processing tend to be fairly complicated requiring a lot of development and maintenance.
From time-to-time, as data network elements are updated, the update typically also introduces changes to the CLI vocabulary and/or grammar. The use of complicated scripts tends to hinder the configuration and control as the scripts also have to be updated to reflect changes in the CLI vocabulary and/or grammar.
Other data network management software vendors have taken other approaches in implementing the network management using CLI commands. Service Activator by Orchestream Holdings Plc. makes use of device driver software that allows a CISCO data network element specific configuration to be made therethrough. Each device driver includes specific application code for managing a data network element. The device driver code is used to extract a current state of a data network element, compare the currently reported state against a virtual state held by network management and service provisioning software, generate a group of CLI commands which are necessary in synchronizing the virtual and real states, and sends the group of CLI commands to be executed by the data network element. The process iterates until the reported current state matches the virtual state. This attempt does not address errors generated by the issuing of CLI commands, rather derives alarms from discrepancies between the current state and the virtual state. This attempt makes use of hardcoded device drivers which contain machine readable object code unintelligible to an analyst attempting to debug such a driver.
These efforts are all laudable, but the productivity of the development and maintenance of such complex attempts for network management and service provisioning suffers. In particular, support for new data network entities, updated CLI vocabularies and/or CLI grammar, requires the whole software application to be re-compiled and re-deployed. There is always a risk of incorporating further errors in existing code when dealing with such large software applications thereby requiring extensive regression testing to verify the integrity of the existing code.
There therefore is a need to devise improved methods of software application code development and maintenance taking into account the above mentioned complexities.